NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/7565

Internet Message Format | 1996-08-05 | 8.5 KB

Path: news1.cris.com!Crawford
From: [e-mail] (CRAWFORD)
Newsgroups: comp.lang.pl1,comp.lang.c
Subject: Re: PL/I and C
Date: 27 Feb 1996 14:13:49 GMT
Organization: Concentric Internet Services
Message-ID: <4gv3it$[e-mail]>
References: <4gh5ru$[e-mail]> <4gn5d8$[e-mail]> <4gril3$[e-mail]> <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: mariner.cris.com

Paul Gorodyansky <[e-mail]> writes:

>So, I'll be more careful and post only to a specific group, because
>OUR talk was about *mainframe* C vs. PL/I, and MOREOVER, about
>*business* applications, involving heavy Text Processing, not about
>*systems* programming.                   ---------------

    Ahem, I do business programming that's _all_ text processing,
and I do it in C. I've never had problems with C being "restricted" in
any way, though I would like to hunt up some regexp code to make life
easier.

    I'll grant that these applications are being written on a UNIX
platform, interfacing with an RDBMS, so it's not exactly like doing
mainframe flat-file work. But... I spent six months doing PL/I
programming on our mainframe, and I can say this:

    Gimmee C _anyday_.

> Again, in *business* applications *Production* environment, where
>   - to be 'closer to Specs',
>   - to be 'easy to read' and
>   - 'easy to maintain'
>   - 'quicker to fix'
> is Vital, PL/I is MUCH better than C.

    All of those factors depend more on structure and design than
on the language, IMHO. I was once handed a PL/I program that in no way
resembled the specs, was a twisted mess of spaghetti code, and took me
a week to figure out. My assignment was to sort the output, so that
the end-of-job report was in state order. I had been using PL/I for
about three months, so I had to pull out the reference book to figure
out procedure calls. I wrote two procedures to handle the sorting and
sorted printing, then "untwisted" as much code as I could.

    The problem wasn't the language, but the utter lack of design
and structure to the code. You can write well-structured,
easy-to-follow code in ALC, APL, or anything. You can write complete
crap in _any_ language.

>   All you, C guys who replied, paid TOO MUCH attention to my note
>about UNIONS, but it's a MINOR thing compared to other AWFUL for
>an *application* programmer  things in C that I listed.
>In systems/low-level tasks C may be Perfect.

    As an *application* _and_ "systems/low-level" programmer, I
find C an adequate and useful tool. While I've occasionally found
tasks which would be better handled with other languages, I work for a
"One True Language" shop, and C is all we have for UNIX. C does the
job, and does it well. Design and structure are the key.

>After so many replies that did not quote these MAJOR things, I am
>posting to comp.lang.C group LAST time, repeating the items, that,
>in my opinion, make C a *bad* choice for
>  an *application* Production environment,
>  where Fix time is *critical*,
>  where are MANY (not ONE package for market) *different* programs,
>  OFTEN to be changed due to Specs changes,
>  often by several engineers, who may see *this* program and
>  *this* data(Huge) FIRST time and have COUPLE hours to fix it.

    Bull. I can fix one of my C functions in less time than it
takes the mainframe programmers to decide if they have a problem. It's
a matter of organization. Our system consists of a few dozen programs,
a 120 Gig database, and literally millions of transactions. C gets the
job done -- well.

>   BUT 'there is no free lunch' and this effectiveness causes
>LESS readability.
>PL/I is reacher, so it's is easier to implement things there and
>make a code more readable.

    I have to disagree. The readibility of any code is a result of
structure, the familiarity of the reader with the language, and the
design of the program. I find it _much_ easier to understand what's
happening when a function named "binary_search" is called, than
if the programmer cut and paste the code for a binary search. That can
happen in any language.

>Select;
>  When ( SUBSTR(INREC,4,1) = ' ' )

if (inrec[4] == ' ')
    {
    };

    Bad example. :-)

>       ....
>  When
>       ...
>  When ( INDEX(UPALPHA,Cur_Tag) > 0  &
>         VERIFY(W_TAG23,'0123456789') = 0 )

if (strstr (UPALPHA, Cur_Tag) != NULL)
    if (!verify_string (WTAG23, "0123456789"))
        {
        };

    Where verify_string is some function that returns zero if all
characters in arg1 are contained with arg2. We've implemented
this function where I work; it's quite possible.

>  When ( String_1 || String_2 = String_3 )

if ((!strcmp (String_1, String_3)) || (!strcmp (String_2, String_3)))
    {
    };

>It is how SPECIFICATIONS look like, so for a person who works
>with this program  FIRST time, it is CLEAR, after reading specs,
>what this part of code is doing.
>     Just TRY to implement it in C !!!
>You will HAVE TO find some 'work around', so it will be further
>                                                        ------
>from specs and the piece of the code will be much BIGGER and LESS
>clear, harder to understand.

    Clue: I always put comments in the code that point back to the
specs. My first step in writing the code is to block out the flow of
the code with comments. I fill in the functionality later, leaving in
comments that refer back to the specs.

>   C has this VERY STUPID limitation - a 'string' in C it's a set of
>bytes with x'00' at the end !
>But, we have x'00' all over our source data !
>For example, we have on-line European Patent Office data (only ONE of
>our 400+ *different* applications), and source file is 40 gigabytes (!)
>FULL of x'00' !!!

    This is called a convention. You can use memcmp, memcpy, etc.
to work with arbitrary byte arrays.

>    Also, C does not have Variable Length Strings, that are VERY
>important for our *application* programs. Again, this feature helps to
>have programs SHORTER, more READABLE, and CLOSER to specs.

    ??
    The entire idea behind NUL-delimited strings is to allow
arbitrary-length strings. The idea was that few people would have need
for NUL's in their data, and those who did could use the mem*
functions.

    I'd love to know what those NUL's are denoting in your data.
Could their purpose be better served with spaces, '0's, or the like?
If they're packed decimal, well, I'm not sure what IBM's done to
support packed decimal under C. It's possible that your problem comes
from having to deal data standard C wasn't really aimed at.

>    And now imagine how IT (foo-o-o) looks in OUR programs, where
>due to this STUPID x'00' limitation, we even can not use THESE
>(not very friendly) functions, and MUST use operations on
>BUFFERS, i.e. mem.. functions, taking through a code Length of
>buffers all the time !

    ??
    Not very friendly? How could anything be more friendly than
strtok? :-)

>   Same Program in PL/I is 100 times more readable and is 100 times
>more easy to CHANGE and FIX.

>So, my points are the following.
>  Open Systems people very often tell that *only* C
>should be used EVERYWHERE, and it's wrong

    I agree. You wouldn't use a chef's knife for everything.
Sometimes you need to pull out the cleaver, the paring knife, or
whatever. The real requirement is that they have to be sharp and _you
have to know how to use them_.

>   For *application* programming *Production* environment with a lot
>of Text Processing, and a lot of *different* and often *changed*
>   ---------------                               -----
>programs, PL/I is MUCH, MUCH better than C:

    I don't agree. I've been able to change C programs much faster
and easier than I've seen PL/I programs change. The difference was
design, not the language.

> - PL/I has wider set of statements, so it is much easier in PL/I
>   to make a code be CLOSE to specs, so next person will understand
>   a code faster and can FIX program faster;

    A "wider set of statements" can be a disadvantage,
specifically in terms of readibility.

> - if a language REQUIRES workaround OFTEN, then it is LESS readable
>   than another language that is reacher.

    "Reacher?" I'll assume you mean "richer".

    True. But C is as rich as you make it. You need a library that
works on "strings" containing NULs? Write or buy one.

--
"They sentenced me to twenty years of boredom, for trying to change
the system from within."
Robert Crawford                [e-mail]
http://www.iac.net/~crawford